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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


Both STD 11, RFC 822 [1] and STD 3, RFC 1123 [2] (Host Requirements) 
require that the email address "postmaster" be supported at all 
hosts. This paper extends this concept to X.400 mail domains which 
have registered RFC 1327 mapping rules, and which therefore appear to 
have normal RFC822-style addresses. 


1. Postmaster Convention in RFC822 


Operating a reliable, large-scale electronic mail (email) network 
requires cooperation between many mail managers and system 
administrators. As noted in RFC 822 [1], often mail or system 
managers need to be able to contact a responsible person at a remote 
host without knowing any specific user name or address at that host. 
For that reason, both RFC 822 and the Internet Host Requirements [2] 
require that the address "postmaster" be supported at every Internet 
host. 


2. Postmaster Convention and X.400 


However, RFC 822 is not the only email protocol being used in the 


Internet. Some Internet sites are also running the X.400 (1984) [3] 
and X.400 (1988) [4] email protocols. RFC 1327 specifies how to map 
between X.400 and RFC 822 addresses [5]. When mapping rules are 


used, addresses map cleanly between X.400 and RFC 822. In fact, it 
is impossible to determine by inspecting the address whether the 
recipient is an RFC 822 mail user or an X.400 mail user. 


A paper by Rob Hagens and Alf Hansen describes an X.400 community 
known as the "Global Open MHS Community" (GO-MHS) [6]. Many mail 
domains in the GO-MHS Community have registered RFC 1327 mapping 

rules. Therefore, users in those domains have RFC 822-style email 
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addresses, and these email domains are a logical extension of the RFC 
822 Internet. It is impossible to tell by inspecting a user’s 
address whether the user receives RFC 822 mail or X.400 mail. 


Since these addresses appear to be standard RFC 822 addresses, mail 
managers, mailing list managers, host administrators, and users 
expect to be able to simply send mail to "postmaster@domain" and 
having the message be delivered to a responsible party. When an RFC 
1327 mapping rule exists, the X.400 address element corresponding to 
the left-hand-side "postmaster" is "Surname=Postmaster" (both 1984 
and 1988). However, neither the X.400 protocols, North America X.400 
Implementor’s Agreements [7], nor the other regional X.400 
implementor’s agreements require that "Surname=Postmaster" and 
"CommonName=Postmaster" be supported. (Supporting these addresses is 
recommended in X.400 (1988)). 


For mapped X.400 domains which do not support the postmaster 
address(es), this means that an address such as "user@some.place.zz" 
might be valid, yet mail to the corresponding address 


"postmaster@some.place.zz" fails. This is frustrating for remote 
administrators and users, and can prevent operational problems from 
being communicated and resolved. In this case, the desired seamless 


integration of the Internet RFC 822 mail world and the mapped X.400 
domain has not been achieved. 


The X.400 mail managers participating in the Cosine MHS Project 
discussed this problem in a meeting in June 1992 [8]. The discussion 
recognized the need for supporting the postmaster address at any 
level of the address hierarchy where these are user addresses. 
However, the group only required supporting the postmaster address 


down to certain levels of the O/R Address tree. This approach solved 
part of the problem, but not all of it. A more complete solution is 
required. 

3. Proposed Solution 


To fully achieve the desired seamless integration of email domains 
for which RFC 1327 mapping rules have been defined, the following 
convention must be followed, 


If there are any valid addresses of the form "user@domain", then 
the address "postmaster@domain" must also be valid. 


To express this in terms of X.400: For every X.400 domain for which 
an RFC 1327 mapping rule exists, if any address of the form 


Surname=User; <Other X.400 Address Elements> 
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is a valid address, then the address 
Surname=Postmaster; <Same X.400 Address Elements> 


must also be a valid address. If the X.400 system is running 
X.400(1988), then the address 


CommonName=Postmaster; <Same X.400 Address Elements> 


must also be supported. (Note that CommonName=Postmaster will not be 
generated by RFC 1327 mappings, but it is recommended in the 1988 
X.400 standard). 


To remain consistent with RFC 822, "Mail sent to that address is to 
be routed to a person responsible for the site’s mail system or toa 
person with responsibility for general site operation." [9]. 


3.1. Software Limitations 


If software is unable to support this requirement, it should be 
upgraded. xX.400 software developers are strongly encouraged and 
requested to support forwarding mail to a centralized postmaster 
mailbox in products. 


It may be possible to support forwarding postmaster mail to a central 
mailbox in software packages which do not explicitly support it by 
applying work-around solutions. For example, some packages support 
creating a mailing list for "postmaster" which has one entry that 
points to the desired centralized postmaster mailbox. Alternatively, 
it may be possible to support a postmaster address using the X.400 
Autoforwarding feature. The software package may also support 
rewriting the address in some other way. 
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Security Considerations 


Security issues are not discussed in this memo. 
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